Loadstar 145/145.d81/t.disc d

Text File | 2022-08-26 | 6KB | 197 lines

 A complete dissection of Gfx-Zone

           by XmikeX


    Note from Jeff: the GFX zone Run
It file contains some of my absolute
favorite SID music.  I just like it.
I give fair warning though that one
of the images may be offensive to
more sensitive viewers.

    The Graphics-Zone demo was
released August 31, 1995.  It was
received with open arms and despite
its simplicity, its unabashed
unorthodoxy allowed it to reach the
third highest spot in the Dec95. NTSC
demo ballots. Gfx-Zone and the other
two files included in the gfx-
zone.sfx package were the
culmination
of ten days of self-taught assembly
programming.  I could not have done
it however without the guidance
obtained from the following sources;

  - Coder's World 1,2, and 3 by
'Wrongway and The Phantom', FOE Press
:)

  - 128 Machine Language for
Beginners by Richard Mansfield

  - Mapping the Commodore 128 by
Ottis R. Cowper

  - Inspiration from 'The Last
Digital Excess Demo', 'Skeletor
Movie', 'Digital Acid', C=Hacking -
Issue #7, the people on the IRC
channel #c-64, 'SYS4096' music by
AMJ, and Thinktank who tragically
passed away months prior to the demo
but had released his amazing
Commodore/Graphics low-res (40 by 25)
artwork to the public a few years
before.

    Graphics-Zone is not an overtly
arrogant and complicated
demonstration.  It consists of 21
Commodore/Graphics (i.e., low
resolution PETSCII) full-screen
drawings (that happen to be *well-
drawn*) placed in synch with a very
nice SID tune running in the
background.  There is little if any
'Top Code' in the demo and since I
wrote it as a beginner, there should
not be anything exceedingly fancy in
the code itself that would preclude
its use as a training vehicle for
those not fully skilled in 6502 ML.
In fact, there are some half-baked
methods in the code that are rather
simplistic even for a beginner. With
this in mind, I hope to share some of
the triumphs and pitfalls so as to
instill a motivative spirit in those
who seek to learn, and perhaps render
a smile in those who already know
:).

    As a great deal of you have
already seen, running Graphics-Zone
is a matter of loading it and typing
"run".  The first two screens pop up
to form the intro sequence where two
C/G pictures are flipped back and
forth slowly to match the tempo of
the music.  When the music speeds up,
the intro pics are abandoned for the
most part and the rest of the C/G
pics in memory fly at you in a mad
attempt to keep up with the tempo.
After a minute or two of this, the
music and pics loop back to their
start sequences and begin anew.
There is nothing mind shaking about
it.  The whole demo is basically a
planned sequence of memory moves for
the pics with an interrupt (IRQ)
driven music player behind it.

    The main block of C/G pics are
located from $3000 to $bfff with
three additional pics at $0800-$0fff,
$2800-$2fff, and $c800-$cff0.  Each
C/G pic occupies 2 kilobytes (KB),
the first KB is the screen data while
the last KB represents color memory,
as follows:

 ; Memory Structure - C/G pictures
 ;
 ; -------------------------------
 $3000  - 0 kilobyte, start of pic 1
 ; ! char data  for C/G pic 1
 ; ------------------------------
 -$3400  - 1 kilobyte, picture 1
 ; ! color data for C/G pic 1
 ; -------------------------------
 $37ff  - 2 kilobytes, picture 1
ends
 ;
 ;
 ; ------------------------------
 $3800  - 0 kilobyte, start of
 picture 2
 ; ! char data  for C/G pic 2
 ; ------------------------------
 $3c00  - 1 kilobyte, picture 2
 ; ! color data for C/G pic 2
 ; ------------------------------
 $3fff  - 2 kilobytes, picture 2
ends

  In actuality, the screen and color
data do not extend right up to the
next page boundary (i.e., at the
$xxff - $xx00 junctions in hex), they
in fact end at $xxe7 (e.g., $33e7,
$37e7, $3be7, $3fe7, etc).  For
simplicity's sake, I did not worry
about the extra bytes at the end, and
I started the each block of pic data
(screen/char or color data) at a page
boundary $xx00. But C/G pics are
simply petscii text and color, right?
Yes, they do not come organized as
shown above and for a short time, the
prospect of extracting them into a
more usable form seemed daunting.
After a few minutes, the solution
came to me.  I read them off the disk
and printed them to the forty column
screen on my 128.  When this was
done, I peeked an image of VIC screen
memory ($0400-$07e7) and VIC color
memory ($d800-$dbe7) and poked the
image to $3000-$33e7 (screen mem) and
$3400-$37e7 (color mem).  Then I
binary-saved them to disk using the
monitor (via the 80 column display of
course).  I repeated this step
twenty-one times because I was
fortunate enough to have twenty-one
quality C/G pics at my disposal :).
In retrospect, I later found out that
certain "taboo" areas of memory such
as the area under the kernel
could have been used to store even
more data, but at the time I was
quite happy to have been able just to
switch out Basic and use the space it
took up.

  What about the rest of the demo,
the music and code, eh?  Not a
problem there. The music player/data
starts at $1000 and heads up to
around $26b0 while the main code for
the demo itself starts at $c000.  I
took all the converted pic files (the
ones I had binary-saved) and used a
packer to relocate them to their
final destinations in memory, along
with the music and code.  Also,
because packers conveniently compress
all data and code into a run-time
executable, I didn't have to worry
about providing a front-end ability
to be able to "RUN" the ML from
basic.  The packer took care of all
this for me, all I had to do was
specify a start address for the
machine-language (ML) code.

      Continued in part 2